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CUSTOMER FRAMEWORK FOR EMBEDDED APPLICATIONS 



Hie present invention relates to wireless telecommunication systems, apparatus and 
methods, especially for short range. The present invention is particularly related to 
5 embedded telecommunications ^paratus and methods, e.g. for short range wireless 
communication. 

Technical Background 

Bluetooth is a short range wireless telecommunications protocol useful for 
10 communication between handheld devices. Further details can be found in 

"Discovering Bluetooth" by M. Miller, Sybex, 2001 and "Bluetooth, connect without 
cables". By J. Bray and C. F. Sturman, Pimtice-Hall, 2001. 

Fig. 1 shows a schematic diagram of a Host Controller Inteifece (HCI) from the 
Bluetooth SIG, HCI Specs, Fig 1 .2, p 544 as appHed to a wireless communication 
15 between two hosts. Host 1 and Host 2. The HCI is functionally broken up into 3 
separate parts: 

HCI Firmware is located on the Host Controller, (e.g. the actual Bluetooth 
hardware device). The HCI firmware implements the HCI Commands for the 
Bluetooth hardware by accessmg baseband commands, link manager 
commands, hardware status registers, control registers, and event registers. The 
term Host Controller means the HCI-enabled Bluetoofli device. 

HCI Driver which is located on the Host (e.g. software entity). The Host will 
receive asynchronous notifications of HCI events. HCI events are used for 
notifying the Host when some&ing occurs. When the Host discovers that an 
event has occurred it will then parse the received event packet to determine 
which event occurred. The term Host means the Ha-enabled Software Unit 

The HCI Driver and Firmware communicate via the Host Controllear Transport 
Layer, i.e. a definition of the several layers that may exist between the HCI 
driver on the host system and the HCI firmware in the Bluetooth hardware. 
These intermediate layers, the Host Controller Transport Layer, should provide 
the ability to transfer data without intimate knowledge of the data being 
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transferred. Several different Host Controller Layers can be used, of which 3 
have been defined initially for Bluetooth : USB, UART and RS232. The Host 
should receive asynchronoxis notifications of HCI events independent of which 
Host Controller Transport Layer is used. 

5 

The HCI provides a uniform command method of accessing the Bluetooth hardware 
capabilities. The HCI Link commands provide the Host with the ability to control the 
link layer connections to other Bluetooth deyices. These commands typically involve 
flie Link Manager (LM) to exchange LMP commands with remote Bluetooth devices. 
10 The HCI Policy commands are used to affect the behaviour of the local and remote 
LM. These Policy commands provide the Host with mettiods of influencing how the 
LM manages the piconet. The Host Controller and Baseband commands. Informational 
commands ,and Status commands provide the Host access to various registers in the 
Host Controller. 

15 The Host Controller Transport Layer provides transparent exchange of HCI- 

specific ioformatioa These transportiing mechanisms provide the ability for the Host to 
send HCI commands, ACL data, and SCO data to the Host Controller. These transport 
mechanisms also provide the ability for the Host to receive HCI events, ACL data, and 
SCO data firom the Host Controller. Since the Host Controller Transport Layer 

20 provides transparent exchange of HCI-specific information, Ihe HCI specification 

specifies the format of the commands, events, and data exchange between the Host and 
the Host Controller. 

The Link Control commands allow the Host Controller to control connections 
to other Bluetooth devices. When tiie Link Control commands are used, the Link 

25 Marnier (LM) controls how the Bluetooth piconets and scattemets are established and 
maintained. These commands instruct the LM to create and modify link layer 
connections with Bluetooth remote devices, perform Inquiries of other Bluetooth 
devices in range, and other LMP commands. 

The Link Policy Commands provide methods for the Host to affect how the 

30 Link Manager manges the piconet When Link Policy Commands are used, the LM 
still controls how Bluetooth piconets and scattemets are established and maintained, 
depending on adjustable policy parameters. These policy commands modify the Link 
Manager behaviour that can result in changes to the link layer connections with 
Bluetooth remote devices. 
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The Host Controller & Baseband Conunands provide access and control to 
various capabilities of the Bluetooth hardware. These parameters provide control of 
Bluetooth devices and of the capabilities of the Host Controller, Link Manager, and 
Baseband. The host device can use these conunands to modify the behaviour of the 
5 local device. 

The Informational Parameters are fixed by the manufacturer of the Bluetooth 
hardware. These parameters provide information about the Bluetooth device and the 
capabilities of the Host Controller, Link Manager, and Baseband. The host device 
cannot modify any of these parameters. 

10 The Host Controller modifies all status parameters. These parameters provide 

information about the current state of the Host Controller, Link Manager, and • 
Baseband. The host device caimot modify any of these parameters other than to reset 
certain specific parameters. 

The Testing commands are used to provide the ability to test various 

1 5 fimctionality's of the Bluetooth hardware. These commands provide the ability to 
arrange various conditions for testing. 

The objective of the HCI UART Transport Layer is to make it possible to use 
the Bluetooth HCI over a serial interface between two UARTs on the same PCB. The 
HCI UART Transport Layer assimies that the UART communication is free from line 

20 errors. Event and data packets flow through this layer, but the layer does not decode 
them. 

The objective of the HCI RS232 Transport Layer is to make it possible to use 
the Bluetooth HCI over one physical RS232 interface betwem the Bluetooth Host and 
the Bluetooth Host Controller. Event and data packets flow through this layer, but the 
25 layer does not decode them. 

The objective of the Universal Serial Bus (USB) Transport Layer is to the use a 
ySB hardware interface for Bluetooth hardware (which can be embodied in one of two 
ways: as a USB dongle, or integrated onto the motherboard of a notebook PC). A class 
code will be used that is specific to all USB Bluetooth devices. This wiU allow the 
30 proper driver stack to load, regardless of which vendor built the device. It also allows 
HCI commands to be dififerentiated from USB commands across the control endpoint 

The above HCI scheme provides a bit-level interface which is dedicated to one 
transmission task. It is however, not very flexible and does not allow easy 
customisation for different applications. 
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Summary of the present inventioii 

It is an object of the present invention to provide a framework so that software 
can be embedded more flexibly into a telecommunications device. 
5 The present invention provides a library of software program products, the 

library comprising a set of routines for an embedded software application requiring 
SW protocol layers, profiles and/or application code embedded on a processor, the 
library providing an interface between the software application running on the 
processor and the SW protocol layers and/or the profiles and/or the application code. 
10 The interface can be between the software application running on the processor and a 
telecommunications module, for example the Bluetooth lower layer SW protocol. 
The mterface may use a telecommunications controller interface communication such 
as the HCI communication for communication with the telecommunications module. 
The software i^jplication can cacommunicate with the telecommunications 
15 module for executmg a telecommunications protocol. The software ^plication can 
also communicate with a hardware ii^ut/ ou(put mterfece. The library can be stored on 
a computer readable medium, such as a CD-ROM or DVD-ROM or a memory or data 
stor^e device. The present invention also includes a host processmg system for 
executing the library of computer programs. 
20 The present invention also provides a telecommunications device wi& an 

interface towards an underlying operating system, to layers of a telecommunications 
protocol and optionally towards any hardware available for an embedded application, 
wdierein the interfece communicates with the telecommunications protocol via a 
telecommunications hardware controller interface such one using HCI 
25 communications. The interface can be an API. 

The present invention also includes an API for providmg fimctions to a 
software application requiring SW protocol layers, profiles and/or application code 
embedded on a processor, the API communicating with tiie protocol layers usmg 
telecommunications controller interfece conummications such as HCI 
30 communications. The present invention also includes an API for providing fimctions to 
a software application requiring SW protocol layers, profiles and/or application code 
embedded on a processor, the API communicating with an operating system of a 
microprocessor and providmg operating system fimctions to the software application. 
The present invention also includes an API for providing fimctions to a software 
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application requiring SW protocol layers, profiles and/or application code embedded 
on a processor, the API communicating with hardware input/output devices for 
providing I/O services to the software application. 

Any of the API's can be stored on a computer readable medium. 
5 The present invention also provides a method of embedding a software 

application requiring S W protocol layers, profiles and/or application code embedded 
on a processor, the method comprising: 

generating an API for communicating with the protocol layers via telecommunications 
controller mterface communications. The present invention also provides a method of 

10 embedding a software ^plication requiring SW protocol layers, profiles and/or 
q)plication code embedded on a processor, the method comprising: 
generating an API for communicating with hardware input/output devices to provide 
I/O services for the software application. The present invention also provides a method 
of embeddmg a software application requiring SW protocol layers, profiles and/or 

1 5 application code embedded on a processor, the method comprising: 

generating an API for communicating with an operating system of a microprocessor 
and providmg operating system fimctions to the software application. 

The present invention also provides a method of operating a 
telecommunications device with an interface towards an underlying operating system, 

20 to layers of a telecormnunications protocol and optionally towards any hardware 
available for an embedded application, the interface operating with the 
telecommimications protocol via a telecommunications contoUer interface 
communications such as HCI communications. 

The present invention will now be described witii reference to the foUowmg 

25 drawings. 

Brief Description of the Drawings 

Fig. 1 shows a conventional HCI interface. 
30 Figs. 2a and 2b show schematic architectures in accordance with embodhnents of the 
present invention. 

Fig. 3 shows a schematic an API in accordance with embodiments of the present 
invention. 
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Fig. 4 shows schematically how an RTOS abstraction layer interfaces with the RTOS 
in accordance with an embodiment of the present invention. 
Fig. 5 shows a preeniptive scheduling scheme in accordance with an embodiment of 
the present invention. Interrupt handler is not shown, only task activity. 
5 Fig. 6 shows a nested prioriiy based intemipt scheduling scheme in accordance with an 
embodiment of the present invention. 

Fig. 7 shows a flow diagram for an application build for use with the present mvention. 
Definitions, Acronyms and Abbreviations 





API 


Application Programming Inter&ce 


10 


BB 


BaseBand 




BT 


Bluetooth 




GPIO 


General Purpose Lq)ut/Ouiput 




HCI 


Host Controller Inter&ce 




IRQ 


Interrupt Request 


15 


ISP 


toerrupt Service Procedure 




LC 


Link Controller 




LMP 


Link Marnier Protocol 




MM 


Non Maskable Interrupt 




RAM 


Random-Access Meinory 


20 


ROM 


Read-Only Memory 




RTOS 


Real Time Operating System 




SDL 


Specification and Description Language 




SIG 


(BT) Special interest Groiq) 




SPI 


Serial Peripheral Intei&ce 


25 


SW 


Software 




TCB 


Task Control Block 




UART 


Universal Asynchronous Receiver-Transmitter 



Detailed description of the illustrative embodiments 
30 The present mvention will be described with respect to particular embodiments 

and with ref^ence to certain drawings but the invention is not limited thereto but only 
by the claims. The drawings described are only schematic and are non-limiting. In the 
drawmgs, the size of some of the elements may be exaggerated and not drawn on scale 
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for illustrative purposes. Where the term "comprisii^' is used in the .present 
description and claims, it does not exclude other elements or steps. Where an indefinite 
or definite article is used when referring to a smgular noim e.g. "a" or "an", "the", this 
includes a plural of that noun unless something else is specifically stated, 

5 The i»esent invention provides a firamework so that software can be embedded 

mto a telecommimications semiconductor device such as an mtegrated circuit or into a 
chip. The telecommunications device may support a telecommunications protocol, e.g. 
a wireless protocol such as BT. For example the BT Layers above an HCL can siqjport 
different profiles and/or Applicatioiis. The semiconductor devices accordmg to the 

10 present invention are particularly suitable for products where no host processor is 
available to provide the process engme to run the applications software. The 
semiconductor devices according to the present invention can include an ASIC, an 
' mtegrated circuit, a multicarrier module (MCM) a printed circuit board or similar. 
Such devices may find advantageous use in small apparatus, e.g. wu«less linked 

15 headphones. 

Fig. 2a shows a schematic blodc diagram of an embedded architecture 
according to an embodiment of the present invention. It comprises hardware such as a 
microprocessor with associated memory and registers, an optional telecommunications 
protocol processing block, e.g. a digital signal processing block whose duty is to 

20 implement specific lower layer telecommunication protocols, and hardware interfiices 
6. Altramatively, the telecommunications protocol processing block may be comprised 
by the microprocessor running appropriate software. The hardware mterfeces 6 may be 
associated witii interrupt service registers 7. Software mmjing on the^ hardware 
devices comprises a Real Thne Operating System 3 running on the microprocessor 2 

25 as well as an RTOS library 5 of routines for use by tiie RTOS. AppUcation software 9 
for the lower layer telecommunication protocols, e.g. the BT stack, is provided for the 
baseband hardware 4 and this can at least partly run on the microprocessor 2. The 
RTOS can communicate wifli the software for the lower layer protocols 9, e.g. via an 
RTOS abstraction layer 11. 

30 The present invention provides a means of seamlessly hooking up a customer 

specific embedded applications or tasks 13 (Application layer. Profiles, BT upper 
layers (RFCOMM, SDP, L2CAP,..) witii the available BT lower stack 9. The interface 
between upper and lower stack is located at the HCI level. The interfece is provided in 
tiie form of an API 12. The main requirement of tiie API 1 2 is to provide flie customers 
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with a Customer Framework (CFW) in which they can be capable of autonomously 
develop and integrate their Bluetooth Host Protocol layers and Applications 13 using 
the system resources of the chip. System resources can be any of the following as 
provided on or off the chip: 

5 

• Volatile or non-volatile memory, e.g. ROM/Flash where the customers* 
application code is stored 

• RAM used by the customer's data structures 

• Processing power from a microprocessor 2 

10 

The API 12 is a very thin set of routines that can be used by the customer SWs 
to access the RTOS system resources, the services related to a telecommunications 
protocol, e.g. as provided by the Bluetooth stack and access to some HW interfeces 
(GPIO pins for example). The interfece is message based. The API 12 has an 

15 identifier, formal parameters and an observable behaviour. It allows procedure calls. 

Fig. 2b shows a simplified version of Fig. 2a giving the basic architecture of 
the customer's software, e.g. tasks 1 to 3, the BT core provided on a single processor 2 
and comprising a RTOS 3 and an RTOS abstraction layer 1 1, the API 12 and the 
hardware mterfaces 6. All functions performed by the RTOS 3 (task communication, 

20 timers, semaphores, etc.. ) are accessible by the customer applications 13 via the 
Customer Framework (CFW), i.e. via the API 12, so there is no need for directly 
calling RTOS functions. Also the access to hardware resources 6 (e.g. GPIO, UART) 
is done via the CFW, i.e. the API 12. The HW 6 never needs to be addressed directly 
by the customer application 13. 

25 An embodunent of the present invention comprises the following building 

blocks: 

1 . BT Baseband controller core 

2. On chip memory, e.g. RAM 

3. On chip memory, e.g. Flash/Boot Rom 

30 4. Hardware (HW) Literfaces (e.g. UART, GPIO, SPI, USB) 

5. An optional customer specific hardware module which communicates with the 
HW interfaces 

6. BT software (S W) implementing tiie host controller layers as defined by BT 
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SIG (e.g. HCI layer, LC and LMP) 

7. an RTOS for a processor cjore, e.g. an RTOS for Thumb (ARM) 

8. On chip microprocessor core, e.g. ARM7TDMI 



5 To allow development of software for the microprocessor including compiler a 
suitable toolkit is required, e.g. the ARM Software Development Toolkit (compiler, 
linker, librarian, etc. . .). For further details of ARM processor cores, see "ARM 
system-on-chip architecture", S. Furber, Pearson Education, 2000, especially the 
section on chq}ters 7 and 13. 

1 0 The chip has on-chip random access memory (RAM) and may have further 

ejrtemal RAM as well as non-volatile or volatile off-chip memory such as FLASH 
memory. .The BT lower protocol stack SW can run on the embedded processor core. 
Depending on the desired configuration and feature-set, an amount of RAM and 
FLASH currently remains unused. This allows embedding applications on top of the 

1 5 BT lower protocol stacL For this purpose, the Customer Framework API 12 is 
provided. This API 12 provides all the necessary interfeces towards the underlying 
RTOS 3, the HW mterfeces 6 (e.g. GPIO, UART, USB, I2C, SSI,.. .), and the BT 
lower stack 9 itself. The API 12 between the customer applications 13 and the BT 
lower stack 9 is preferably conformant to the HCI specification. 

20 

1. The API 12 

API 12 (Fig. 3) is constructed by considering the technical functions \*iiich 
need to be provided for the associated software components v\iiich will access it The 
API provides full control of these functions. API 12 provides functions to a software 
25 application reqmring SW protocol layers, profiles and/or appUcation code embedded 
on a processor. The API communicates with the protocol layers using 
telecommunications controller interface communications, e.g. HCI communications. 
The API 12 may comprise at least 3 types of API for controlling different functions: 

30 An RTOS API 14 which provides memory management, task managemoit, inter-task 
communication, timer management and semaphore handling. 

A telecommunications contioller mterface API 15, e.g. an HCI API y^ch provides 
commands conformant with the controller inteil&ce and handles events, e.g. HCI 
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conformant commands and handles HCI events. 
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A Hardware (HW) interfeces API 16 which provides handling of the 10 devices, such 
as GPIO, UART handling as well as interrupt handling. 

5 

In addition a miscellaneous API 17 for general tasks is provided which provides 
startup and initialisation, background tasks, e.g. a low priority thread, exception 
handling and tracing and logging. 

10 The four API's 14-17 may be integrated as a single API or as four, three or less 
separate API's. 

U HCI API 

The BT Host Controller Stack (Lower Layers Stack) includes all baseband 
functionality and SW layers up to the lower HCI layer. This HCI layer is a 

15 standardized interfece and is the interface for defining the API 12 associated to 

Bluetooth functionality. However, since the customer Host Protocol stack/Application 
is going to be embedded and running in the same processor as the Host ControllCT 
Stack, the HCI Layer and HCI Transport Layer can be considered as virtually empty. 
As a result, the HCI API which is part of API 12 to be used for communication with 

20 the customer application is based on the format of the HCI commands and events. 
From a physical point of view the transport mechanism is implemented by means of 
RTOS message passing and/or direct function calls vfbsxL the customCT's tasks or other 
tasks want to send HCI Conamands, HCI Data and HCI Events between each other. For 
example, a customer L2CAP task would prepare a buffer containing a standardized 

25 HCI command (as they would in a two-processor solution) and call a routine send HCI 
command (buffer *) which would send the command to the LMP. If the Host Interface 
Transmission Task wants to send a HCI Event, it could do so by sending a mess^e to 
the L2CAP task or by providing a callback routine defined by the customer. For some 
specific HCI commands the customer would need to know the format of those 

30 commands and use the same mechanism as the standard HCI commands. 



UHW Interfaces API 

The API 12 also provides the means for the customer application to read/write 
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in any of the hardware interfaces such as GPIO pins that are free for customer use. For 
example, the API should provide the means for the customer to configure the free 
GPIO pins as input, output or interrupt 

The customer ^plication might need to have access to an interrupt device (fr 
• example a button in a headset) by using one of the GPIO pins. This could be done 
two ways, for example: 



10 



15 



30 



or 
m 



The API defines a routine to read the status of the GPIO pins and the customer polls 
the status using this routine 

An interrupt is triggered whenever the status of the any of the customer GPIO pins 
changes. A customer task can register by means of an API routine to receive a message 
indicating that there was a change in one of the GPIO pins, and the message is sent by 
a defined ISR indicating the current status of the pins. 

2. The structure and interfaces of the lower layers of the baseband Software Protocol 
Stack 



2.1 Link Controller 

20 The LC provides the mtelUgence for driving the baseband hardware and deals with 
packet level and slot level control. The LC functionality can be spHt m three major 
parts: 

• Programming the baseband registers with the requuBdlmk information to allow 
it to transanit or receive in the next slot or packet 

25 • Allocating future slots between different connections and states 

• Receivmg data from the baseband and sending it to the higher layers 



The programming of the baseband registers has to be done as rapidly as possible to 
aUow the radio to be programmed in time to transmit or receive m the next slot 



2.2 Link Mane^er Protocol 

The link manager manages the device and connections m the long term. Its primary 
tasks are: 
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• Instructing the link controller to move between states 

• Implementing the LMP protocol 

• Implementing the HCI specilBcation 



5 The HCI transport is a self-contained separate task in order to keep the transport details 
transparent to the LM. 

3.RT0S 

Embodiments of the present invention provide services via the CFW \diich can 
10 be mq)ped mto a RTOS ABSTRACTION LAYER and/or an operating system (OS). 
The way these services are mapped much depends on a balance between portability 
and functionality. In one preferred embodiment the CFW is mapped into the RTOS 
ABSTRACTION LAYER instead of doing it directly into the RTOS, since a change m 
the RTOS would be transparent to the CFW. It is not necessary for the RTOS 
1 5 ABSTRACTION LAYER to provide all the possibilities available from the RTOS. 
Hence, the present invention includes defining some services offered by the CFW in 
terais of OS services, and some being defined as an extension to the RTOS 
ABSTRACTION LAYER. 

The API provides a subset of the possibilities offered by the OS services in 
20 order to avoid the customer to abuse the system. None ofthe OS files should be visible 
to the customer. The API is preferably based as much as possible in the RTOS 
ABSTRACTION LAYER. 

Some maximum configuration parameters (for example maYimntifi number of 
tasks to be created by the customer) can be defined in a special customer configuration 
25 file. This file is not visible or modifiable by the customer, but contains configuration 
parameters relevant for the API and used at compilation time before delivery ofthe 
CFW library to the customer. 

The API includes calls to retrieve the maximum values configured for RTOS 
resources used by the customer application. It is responsibility ofthe customer to bind 
30 to these although the API will control that the customer application is not trying to 

cross the set limits, for example a customer application trying to create more tasks than 
allowed. 

The API 12 is preferably based not on macros but on routine calls in order to 
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hide implementation and details of calls to the OS. 

The RTOS is preferably a real-time multitasking system" that allows flie 
concurrent execution of different application program modules (tasks) on a single 
processor in an orderly manner. Preferably, a preemptive priority-driven scheduling 
5 algorithm is used (Fig. 5), which ensures that the highest priority task that is ready to 
do useful work will always have control of the processor. This pre-emptive mechanism 
can coexist with a time-slicing one as explained later one. The services of the 
operating system may be those provided by standard RTOS and may include, amongst 
others, buffer allocation, memory management, inter-task conmiunication and 
10 synchronization, internq)t handling, timer maiiagement, etc... 

The foUowmg are preferable capabilities that are offered by the RTOS and that 
determine what type of services the API can provide in the development framework. 

3.1. Startup and shut down 

15 The operatii^ systCTOi can be started up and shut down by the respective calls. 

The mitialization and shutdown of theAPI itself can be done as part of an OS Restart 
and an optional OS Exit procedure. The initialization is needed but 4ie shutdown is not 
essential. Restart procedures can be procedures to be called during OS startup. It does 
not mean they are called during an OS restart. Within that initialization the API will 

20 provide an empty routine to be defined by the customer for customer specific general 
initialisatioiL This initialization is done afler OS has been initialized. It is used in case 
the customs needs to do initialization common to all tasks. Furthermore, the API will 
guarantee lhat for every task that is bemg started dynamically, an associated 
initialization routine (as defined by the customer) will be called once before the task 

25 enters the main message waiting/handling loop. 

With the call to start up, a kemel is mitialized, it enables the interrupts and 
executes the sequence of application Restart Procedures provided in the Restart 
Procedure List of the S3^m Configuration Module. User provided Restart procedures 
could invoke relevant services to start tasks and initialize interval timers 

30 When the operating system (OS) shutdown is called, the operating system 

executes the sequence of application Exit Procedures (to restore original environment 
prior to the launch of the OS) provided in the Exit Procedure List of the System 
Configuration Module, and then it returns to the point where OS was launched. 
Shutdown is optional. Alternatively, once the system is started up it can run until reset 
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3.2. Task N^nagement 
3.2.1 Task Creation 

5 For Has creation of tasks tiiere are different possibilities offered by the OS 

services: 

The customer can define the tasks dynamically during runtime. TTiis is the most 
flexible scheme for the customer in case the customer's protocol stack configuration ir 

10 terms of number of tasks is not known at compilation time. It has the advantage tiiat 
the CFW library does not need to be recompiled, but extra code needs to be added to 
the fiamework to provide protection to runtime errors caused by the customer's 
application not respecting the indicated system limits. The API can use flie memory 
management services provided by OS in order to manage the shuctures necessary for 

15 the d^nition of each task. 

Ahematively, flie customer can define tiie tasks statically in the configuration file, but 
this configuration is somehow hooked up into the OS System Configuration module 
and tiien the customer's tasks would start up as part of the OS startup sequence. This 
20 solution is sunpler and less prone to runtime errors, but then the CFW library would 
need to be reconq)iled and it would mean that sources would need to be released to the 
customer. 

Hence, in embodiments of the present invention tasks can be created in a static way via 
the Configuration Module processed at Startup or dynamically fi:om Restart 
Procedures or other Tasks by means of tiie corresponding service calls. The maxunum 
number of tasks in the system is preferably User Defined and it sets an upper limit to 
the number of tasks tiiat can be created by the application. When creating a task 
dynamically the plication provides, amongst others, a 4-character tag that will be 
associated with the task, a pointer to the task entry point code and the time slice 
associated with the task if supported. Anotiier important parameter in the definition of 
the task is the pointer to a statically allocated (reserved at compilation time) RAM 
region to be used by the OS as storage for the tasks' Stacks and Task Control Block. 



25 



30 
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The OS returns to the application a Task Id that can be used to reference that task in 
other OS service calls. 



3.2.2 Task Deletion 

5 Even though the customer ^plication might create tasks dynamically, it might 

be possible that it will never need the expUcit deletion of tasks. In most cases the 
dynamic creation is just used because protocol stacks need to configure and register 
different layers when the whole stack is started up but this configuration remains iiie 
same during the "rest of the protocol stack life". However, in case the customer 

10 appUcation needs this service or memory usage of the system should be improved, this 
service could be used for deletion of the associated unnecessary resources. 

Hence, m embodiments of the present invention, tasks can be dynamically 
deleted or killed by using the extended task termination procedures provided by the 
OS. It allows the de-allocation of resources used for the management of the task by the 

15 OS (stack and TCB for example) and the call of the task's Task Termination 

Procedure. Tasks can kill themselves. The main parameter for the deletion of the task 
is the Task Id. 

3.2.3 Task Ending 

Forcing the endmg of the task and returning control to the RTOS scheduler is 
20 useful in some situations, for example to exit easily fi;om very deep nested execution. 
However, if the customs ^plication has in place correct design and coding 
procedures this situation should not arise since it is not a good programming practice 
anyway. Therefore, it is not essential to support this service in the API. 

Hence, a task normally ends when its task procedure returns to the OS. 
25 However, under some cmjumstances a task may wish to end but due to procedure 

nesting, cannot easily do so. In such cases the task can invoke an OS service to end the 
task and retum control immediately to the OS scheduler 

3.2.4 Task Execution 

The preemptive nature of the RTOS together with the task prioritization will 
30 have a key role in preventing the customer SW fiom affecting the performance of the 
lower layers. As in any other protocol stack, the real time constraints of the lower 
layers are much tighter than tiie higher layers. Hence, the real time needs o^ for 
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example, the LMP layer (not to mention the LC) of the lower stack, are more stringent 
than that of other layers above HCI. 

It can be stated that the LC activities should not be affected by the addition of 
customer's defined tasks, 

5 The rest of the LC executes with the highest priority IRQ associated 

with RTOS. Preferably, all user's tasks are executed with interrupts enabled and 
therefore the ISPs would always preempt the execution of such tasks. The customer 
application should not be able to disable the interrupts or perform any actions that 
might affect the normal intermpt and priority handling of the RTOS. For example, the 

10 API should not provide any routines to provide to the customer application with such a 
capability.. 

For the rest of the S W tasks (LMP, Host Interface Tx), which run as a normal 
RTOS tasks, interference from custom^'s tasks can be avoided by using task 
prioritization. If the customer's tasks run with a priority lower than the priority 

15 assigned to the S W tasks, neither of these SW tasks will ever get preempted by 

customer's tasks ready to be executed. As a matter of fact, the stated requirement on 
the priority level assigned to the customer's task, will guarantee that any task will 
always preempt any customer's task and take control of the processor for as long as it 
is necessary. Only when other tasks are idle and no interrupts are generated will the 

20 customers' task be scheduled by the RTOS. For example, the creation of customers' 
tasks by means of the API can be deiSned in such a way that the priorities assigned to 
the customers' tasks will always be lower than the priorities assigned to our tasks. 

Tasks can request from the OS a special privileged mode in which interrupts 
are enabled but no higiher priority tasks can kick in, not even the Kemel Task and the 

25 OS preferably offers the possibility for a task to change its own priority or other task's 
priority on the fly. These special services from OS should not be open to the customer 
application in the API, 

One of the problems that can arise from allowing customer development of 
applications to run with an API is the possibility for the customer to define a task that 

30 never returns control of the processor to the RTOS. This would not affect in any way 
the processing associated with other tasks, smce the preemptiveness of the other tasks 
other tasks would be scheduled anyway. However, if this customer task had a higher 
priority than the other customer tasks, the whole customer application would block. In 
this case buffers allocated by the lower layers and sent to the higher layers for 
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processing might never be de-allocated again and run out of memory would be 
possible causing some runtime exception. If all the customer tasks run in a time sliced 
feshion, misbehaviour in a customer task would not affect the rest and the problem 
would be reduced. Time sUcing would not affect other tasks since time sUcing is done 
5 for tasks with the same priority and other tasks run at higher priority. Means to detect 
the problem can be provided, e.g. as an SW watchdog, if not provided by HW. A HW 
watchdog can also be provided. A special task can be defined with a lower priority 
than that of the rest of the customer tasks plus a timer to act as a watchdog. The timer 
would be restarted every time the watchdog task is scheduled. If the timer expired, the 

10 associated Timer Procedure would be tiiggered. It can be guaranteed timt Timer 

Procedures are scheduled if aU tiie Thaer Procedures are executed in tiie context of the 
Kernel Task (priority 0). In tiiis Timer Procedure tracing or logging information about 
the abnormal condition can be provided. It can be used as a breakpoint in debugging 
environments with emulators or provide a soft/hard reset of the board m production 

15 systems. 

Accordingly, the present invention provides an API that will allow the 
customer to define tasks with different priority levels. The API can provide a set of 
priorities to the customws' task, all being lower than OS tasks. 

In embodiments of the present invention, the RTOS starts a task execution at 
20 the task's start address specified in flie task's definition. Since tiie OS is a preemptive 
RTOS, tiie task execution is suspended if ano&er higher priority task becomes ready 
for execution (which can happen if tiie executing task performs an operation fliat 
invokes a task of hi^er priority - see Figs. 5). Once a task is scheduled, it inhibits tiie 
perfoniiance of lower priority tasks and continues to execute until it decides to 
25 relinquish control by caUs to tiie OS (return to tiie Task Scheduler, wait for event, wait 
for timed interval, etc. . .). For example, a real time application which is below the API 
12 level has priority over a task such as LM above the API level (see Fig. 5). As soon 
as tiie condition tiiat suspended tiie task stops, tiie task is resumed at the point it was 
suspended. 

30 During the execution of a task tiie interrupts are enabled. However, tiiey can be 

disabled for a short period of time or tiie task can request a special privileged mode in 
which interrupts are enabled but no higher priority tasks can kick in (not even tiie 
Kernel Task). 

AppUcation task priorities in a range &om 1 (highest) to 127 Gowest) inclusive. 
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The Kernel Task runs with priority 0. The OS offers the possibility for a task to change 
its priority or other task's priority at runtime. The OS can support time slicing for tasks 
having the same priority level. The OS can be configured statically to siqjport time 
slicing by specifying it in the System Configuration Module, or otiierwise it can be 
5 dynamically enabled and disabled at runtime. One of the parameters for tiie definition 
of a task is tiie time slice in system ticks assigned to it. This specifies the number of 
system ticks that the scheduler will give to the task before the task is forced to 
relinquish flie processor to another time slice task (of the same priority). If the time 
slice is zero the task is not time sliced. After the task creation tiie time slice associated 
1 0 with a task can be changed dynamically. Once time slicing is enabled, the task is time 
sliced with other time sliced task of the same priority. 

3.2.5 Instantiation 

The OS does not need to support instantiation within a task and task instances 
can be implemented as different tasks in the system The RTOS ABSTRACTION 
1 5 LAYER can implemrat macros that expand a multi-instance task into several OS 
tasks. For example, there can be two qxiMoaches for tiie support of instantiation in 
customer's tasks: 

Use of tiie RTOS ABSTRACTION LAYER approach with an explicit kemel task 
20 definition for each instance. This approach requires the different tasks to have their 
own identification, Stack space and Queue and therefore the customer code needs to be 
aware of that for inter-task communication. 

Provide only single instance tasks and let the customer implement instantiation. The 
25 instantiation is done witiiin the customer task. In this case the task identification, stack 
space and queue are common for all tiie instances of tiie task and the customer needs to 
provide the means for instance separation (for example including instance number in 
every signal sent to a multi-instance task). In tiiis case even though tiie tasks' Stack is 
common, every instance would need to have their own data space to maintain private 
30 data across transitions (dynamic memory allocation could then be used for that). 

Hence, in accordance with embodiments of the present invention the RTOS need 
not support instantiation explicitiy as part of its services. Instances can be implemented 
as separate tasks entities tiiat use the same code stack as long as this code is re-entrant 
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Message Exchanges and Mailboxes have an associated id to be tracked by the 
application and an optional Tag. A Message Exchange can be dynamically deleted (if 
no task is waiting on it or no messages are being held). 

5 3.2.6 Message Passing 

If the customer appUcation needs to support message priorities this can be done 
by the use of Message Exchanges and if not, Mailboxes can be sufficient It is 
recommended for code size reduction to have only one or other in the system but not 
both. When 9. customer task wants to send a signal to another task, it needs to know 
1 0 only the Task Id or Task tag of the recipient task. The API can then find out by means 
of OS system calls what is the associated Message Exchange Id or Mailbox Id 
associated to the task. 

The mode in which the sending task waits for acknowledgment of the reception 
of the message need not be supported since it does not seem necessary and can raise 
15 unnecessary problems when used by the customer application. 

The API should aUow the customer ^Ucation to retrieve the maximum 
number of bytes that can be passed by value in a message envelope. It is the 
lesponsibiHty of the customer SW to allocate a buffer and use it to pass it in the 
envelope if the size exceeds that maximum. 
20 The API preferably provides routines to let the customer copy byles into the 

allocated buffers. M this way the API can provide range and pointer checking. 

Accordingly, in the RTOS, according to embodiments of the presait invention, 
fliere are two different input queue structures that can be associated to a task. One is 
the Mailbox and the other the Message Exchange. The main difference is that the 
25 Message Exchange supports 4 different levels of priorities whereas the Mailbox only 
supports a smgle priority level. It is recommended by to use in the system one type or 
the other, but not the two at the same time in order to minimize the code size of flie 
system (the OS can be configured to leave out certain parts of functionaUty). When ■ 
configuring a Mailbox or Message Exchange the maximum number of messages they 
30 can hold (depth) has no effect on memory requirements. Message Exchanges and 
Mailboxes have an associated identifier to be tracked by the application and an 
optional 4-character tag. A Message Exchange can be dynamically deleted. 

In the RTOS any task can send a message to another task as long as it knows 
the recipient task's Message Exchange Id or Mailbox Id. These Ids can be derived 
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from the Task Id by meaDS of system calls. 

The basic structure used to manage the message passing between tasks is the 
envelope. The OS maintains a list of free envelopes. When a task wants to send a 
message to another task, it needs to specify the destination mailbox, priority (0 to 3) 
5 and if flie sender needs to wait for acknowledgment of reception. A free envelope is 
allocated by the OS and all message parameters are copied by value (including array) 
into the envelope. 

The maximum number of parameter bytes that can be sent in a message is 
defined in the System Configuration Module. It is preferred to know what is the 
10 absolute maximum message size that can be sent in the system (by value in the 

envelope it is). This maximum needs to be known and if the a bigger message needs to 
be sent, the CFW library can be re-complied again or else buffer allocation is 
necessary as well as passing the buffer pointer. 

3.2.7 Message Exchange Tasks 

15 Message Exchange Tasks allow the runtime CTeationoftasks and their 

associated private message exchanges. It is done by means of a system call that ties the 
task and message exchange up together. 

3.2.8 Buffer Management 

20 After considering the amount of RAM memory that is left for customer's 

purposes, chunk of memory vMch is gomg to be used for the different customer's 
needs can be defined statically. One of these needs is the definition of buffer pools of 
different sizes for the messages exchanged betweai the different customer's tasks. 
Common buffer pools for the BT Lower Layers and the customer's Higher Layers can 

25 be used. However it seems much better for proper dimensicmng to fiave different sets 
of buffer pools for BT Lower Layers and customer's IBgher Layers. The total amount 
of memory available for customer buffer pool definition is fixed when the CFW library 
is delivered to the customer. The customer is allowed then to define certain 
configuration values (number of buffer pools, size of the buffers, number of the 

30 buffers, etc...) in a Customer Specific Configuration File. This file should give enough 
parameters so that the customer specific startiq) sequence triggers the API calls to 
create the buffer pools. The API should control that the total RAM size the customer is 
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trying to aUocate for the buffer pools does not exceed the maximum size aUocated 
statically in the CFW library. If still within the limits, the API would call the 
appropriate OS routines to do the real creation of pools. Some parameters for these 
caUs can be provided by the customer and others can be derived by the API. Of course 
5 the Pool Ids returned by the OS would be relayed back to the customer's appUcation 
for later use m other API calls. 

When the customer application requests/returns a buffer from/to a pool, the 
API maps it into the appropriate OS calls. In case of buffer allocation, the OS aUows 
for the task to wait and block mtil a buffer is available but this should not be 
10 siqjported since it can produce unpredictable effects m the customer code. This case 
can be treated as a SW exception due to badly configured or badly predicted customer 
configuration parameters. 

Unless expUcitly needed by a customer, the support for the sharing of 
ownership over buffers and therefore the AME API does not need to support the 
15 manual increase of the buffer reference count Ownership of a buffer is transferred 

when the buffer is sent to another task by means of a message sending, Olher calls to 
give back status values with the buffer sizes, number of buffera ftee, etc. should be 
supported by file API. 

Hence, m accordance with embodiments of the present invention, buffer 
20 management preferably provides access to multiple pools of buffers (fixed size block 
of memory). Application modules can request the Buffer Manager to get a buffer from 
a pool. If no buffer is available the task can wait for the buffer (with a timeout to stop 
waitmg or vdth mdefinite waiting). If the buffer becomes avaUable, it is given to the 
task waiting at the top of tiie buffer's pool wait queue. 
25 Buffers can preferably be shared and owned by different tasks and are only 

retumed to the pool when the last task releases it. 

Speed of execution does not depend on number of pools or buffers and the 
number of pools or buffers is only limited by memory avaUability and is defined in tiie 

30 3.2.9 System Configuration Module. 

A pool of buffers consists of any number of buffers of a uniform size measured 
in bytes (multiple of 4 and greater than or equal to tiie target dependent minimum). 
Buffers can be created dynamically or can be predefined to be created during startup. 
The OS supports calls to create a buffer pool before tiie ^Ucation can use it 
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The parameters are the number of buffers in the pool, the size of each buffer, a pointer 
to RAM storage for all the buffers in the pool and an optional 4-character Tag. It then 
returns a buffer pool id that can be used by the application to identify the buffer pool. 
The OS has calls to derive the buffer Pool Id from an allocated buffer pointer and or 
5 from a 4-character Tag. There is an associated call to delete the complete buffer pool, 
even though this functionality might not be needed. 

After the pool has been created a task can request a buffer from the pool. This 
call returns a pointer to the first byte of the buffer. The task can wait if there are no 
buffers available Alternatively, this is not used. Instead it can be considered as a SW 
10 exception due to bad dimensioning of buffer pools. The task can de-allocate the buffer 
with the appropriate call in which the pointer to the first byte of the buffer to be de- 
allocated is given. If the use reference count is zero the OS returns it to the pool. The; 
OS manages tbis reference count and hides the real buffer de-allocation from the tasks. 
This can be used for buffer sharing. 
15 Nnumerous calls are provided to increase the reference count manually (for 

buffer sharing), to give back status values with the buffer sizes, number of buffers free, 
etc. 

3.2.10 Memory Management 

The issues raised for the Memory Management are quite similar to those of the 
Buffer Management. However, Buffer Management is used for the allocation of 
message buffers of predefined sizes, whereas the Memory Management is used for the 
dynan[iic allocation of arbitrary sized chunks of memory for piirposes different than 
message passing. Part of the memory allocated statically for customer ^plication 
purposes should be dedicated for the dynamic allocation of memoiy if so needed by 
the customer application. The total amount of memory available for customer memory 
pool definition is fixed when the CFW library is delivered to the customer. The API 
would control that the total RAM size the customer is trying to allocate when creating 
the memory pool does not exceed the maximum size allocated statically in the CFW 
library. If still within the limits, the API would call the appropriate OS routines to do 
the real creation of the memory pool. Since only one big mraiory pool with a big 
memory section is needed to be created, the Pool Ids returned by the OS can be kept 
within the API and would not be relayed back to the customer's application. When the 
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customer application requests/returns a memory block it does not need to specify the 
Memory Pool Id to the API. The API would map it into the appropriate OS calls after 
filling in flie stored Memory Pool Id. 

The Stack allocated for every customer task could be taken from the Memory 
5 Pool from where the customer's task can allocate memory blocks or else be part of a 
special Memory Pool allocated in the customer dedicated RAM. 

The Memory Manager permits any block of memory (including the ones 
acquired from the Memory Manager) to be treated as memoiy from v/iach smaller 
private blocks can be dynamically allocated. This feature can be used by the API to 
10 partition memoiy into different Memory Pools but the API will not open this for 
customer use (a task can get a memory block dyoamically but cannot request that 
block to be converted into a manageable Memory Pool). 

Even though the OS can support the shared ownership of a memory block by 
differait tasks by means of the manual increase of the reference count, the API does 
15 not need to siq>port it but it can be provided. Data sharing between customer's tasks is 
not considered a good programming practice, especially since the message passing 
should be enough for the inter-task communication of the customer's Higher Layers. 

When a customer's task frees an allocated block of memoiy, the API can check 
the pointer consistency of the operation (with the potential help of the status returned 
20 by the associated OS call). 

Even though a task can request the OS for the size of a memoiy block (in case 
the task is given ownership of a block by another task), the API need not provide that 
service. The only data sharing between customer's task should be that of buffers 
passed via messages. 

25 Since the comiption of the contents of a memory location outside the memoiy 

block can have unpredictable and potentially disastrous effects, the API should provide 
control and checking of all the used pomters, checking of proper index ranges, etc... 
Memory copies should preferably be done through the API. 

The API need not support task requests to grow or shrink the size of a memory 

30 block to suit the task's needs. 

The API need not support the deletion of an entire memoiy pool smce it is not a 
common situation in embedded RTOS applications. 

The Memoiy Manager aUows the dynamic allocation of contiguous memoiy 
blocks. Requests to allocate and de-allocate the memory blocks are done to the 
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Memory Manager. The Memory Manager permits any block of memory (including the 
ones acquired from the Memory Manager) to be treated as memory from which 
smaller private blocks can be dynamicaUy allocated. This feature allows a task that has 
well defined memory requirements to reserve a block of memory for its own private 
5 use. The task can then call the Memory Manager to control the allocation and release 
of smaller blocks from within the larger block. 

High level language memory management procedures (as malloc, calloc or 
free) camiot be called from concurrently executing tasks since the procedures are 
usually non-reentrant. 

10 In accordance with embodunents of the present invention the Memory Manager 

allows the static and dynamic defmition of a set of memory pools, each pool 
containing a set of one or more sections of contiguous memory. Then Memory 
Manager procedures are called to obtain a memory block of any size from a particular 
memory pool and to release it back to the pool yiben it is not longer required. 

15 As for the buffer pools, memory block ownership can be increased manually so 

that tasks can share them. The number of memory pools and amount of memory in the 

memory blocks is only limited by memory availability. 

A memory pool consists of any number of memory sections of varying sizes 

measured m bytes (size multiple of 4 and greater than or equal to a target dependent 
20 minimum). However, a manory pool usually consists of a single large memory 

sectiorL 

When defined statically, memory pools and sections can be predefined in the 
System Configuration Module. 

When a memory pool is created the Memory Manager returns a memory pool 
25 id. The application needs to keep track of that id. A 4-character Tag can be assigned to 
that id and this id can be derived from the tag by means of a particular call. After an 
empty memory pool has been created, calls can be made to add memory sections to 
lhat particular memory pool (size in bytes of the section plus the pointer to the 
beginning of the section). There are no limits on the number of memory sections 
30 attached to a pool. The manager treats 2 sections as disjoint pieces of memory even 
though they might happen to be contiguous. The manager maintains a linked list of 
free memory blocks, whidi is internal to the manager. 

A task can request a memory block of a particular size in a memory pool. If a 
block of that size is found the manager will return it with its actual size (eventually 
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larger than asked). If no free blocks of at least that size are available, the manager 
returns and error and an indication of the largest size available. The OS provides a call 
to derive the Pool Id from a given allocated memory block. When the task has finished 
usmg the memory block it can release it back by means of anothCT call. The caller 
5 specifies the block to release by giving the pointer allocated previously. The Memory 
Manager decrements the user count and if it is zero it retums the block to the free list 
If there are adjacent blocks free they are merged to form a larger free block by the 
Memoiy Manager. The user reference count can be incremented manually to provide 
memory sharing between tasks. 

10 A task can request the OS for the size of a memory block (in case the task is 

given ownership of a block by another task). If a task cornq)ts the contents of any 
memory location outside the memory block, the effects are unpredictable and 
potentially disastrous. 

The OS allows requests from a task to grow or shrink llie size of amemory 

15 block to suit the task's needs. If it is to be shrunk a piece is carved from the high end 
of the block and a new fragment is added to the free list If it is to be grown, the 
Manager checks if there is an adjacent block in the upward memoiy direction that is 
free and a larger block is produced. 

The application can delete an entire memory pool. It is responsibility of the 

20 application to make sure that no blocks are still being used when this happens. 

For private mraiory allocation, a task can use request the OS for the creation of 
the memoiy pool and pass a pointer to a private area of memoiy whose access is to be 
controlled by the Manager and the size of it. This private area can be a block obtained 
from another pooL The Manager converts it to a memory pool and retums an id that is 

25 private for the task (as long as the task does not make it public, that pool can be 
considered private to the task). 

3 .2. 1 1 Synchronization Management 

Considering that the customer application can be running tasks implementing 
30 activities with low real time constraints, it is considered imnecessary to use 

synchronization mechanisms at that level. Therefore, the API need not provide any 
means for synchronization between customer's tasks. Moreover, such mechanisms are 
too prone for misuse. The customer's task are preferably normal standard tasks based 
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on clearly defined SDL transitions supported by the message passing mechanism 
provided aheady by the APL 

The OS can provide different synchronization mechanisms. One of them is the 
provision of sem^hores with priority queuing and timeout There are two types of 
5 semaphores; resource semaphores and counting semaphores. A resource semaphore is 
a binary sem^hore to limit access to each resource to a task at a time (the ownership 
and release of a resource is governed by calls to the Semaphore Manager). The 
counting semaphores can be used for mutual exclusion and resource management The 
task can specify the priority of tiie request and an optional timeoiJt If a task, ISP or 

10 Timer Procedure signd the seni^hore,tiie Semaphore Manager grants tiie access to 
the semq)hore to the task waiting at tiie top of the semaphore queue. 

The other type is the provision of events. A task can request the Event Manager 
to suspend its execution until one or more events occur. When a task, ISP or Timer 
Procedure detects an event, it signals tiie event to tiie Event Manager, which checks 

15 which task is waiting to tiiat combination of events and resumes its executioa 



3.2.12 Timer Management 

The API should provide tiie means for the customer's tasks to start and stop 
timers. As Timer Procedures are executed in tiie context of the Kernel Task and special 

20 care must be taken in tiie type of actions defined in tiie Timer Procedures, the API 
should not leave open to tiie customer tiie possibility to define such Timer Procedures. 
Instead, tiie Timer Procedure will be used by tiie API to send tiie corresponding expiry • 
message to the customer tasL 

The timer management as defined in tiie RTOS ABSTRACTION LAYER 

25 provides all expected fimctionalily for tiie customer and tiierefore tiie API can be based 
on calls to tiie RTOS ABSTRACTION LAYER instead of direct calls to tiie OS. 

Timing in the OS can be unplemented using interval timers (e.g. 32-bit 
counters). The timing resolution is based in multiples of tiie system tick (tiie system 
tick is based in tiie HW Timer), The OS preferably provides tiie means to create 

30 timers. The associated parameters are the timer period (one shot or periodic), a pointer 
to a Timer Procedure (to be executed when the timer expires) and an optional 32-bit 
application dependent parameter. A Timer Id is retimied which needs to be managed 
by tiie application. A 4-character Timer Tag can be assigned to a Timer Id The timer 
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is started by means of a separate call giving the timer interval and stopped by giving a 
zero interval. A task can read the time remaining via the coircsponding call, 

A Clock Handler triggers the Kernel Task if required (at the user defined 
system tick interval if and only if there is an outstanding timing activity required in the 
5 system). If a timer has expired, the Kernel Task executes the associated application 
dependent Timer Procedure (as the Kemel Task has priority 0, the Timer Procedures 
are executed at the highest task priority in the system). A Timer Procedure must not 
use any directives that would in any way force the Kemel Task to wait for any leasoa 
A subset of services to send messages, signal events or wake tasks can be used in the 
10 Tmier Procedure. The OS provides calls to convert milliseconds in system ticks and 
others alike. The maximum number of appUcation interval timers is defined in tiie 
S:^tem Configuration Module. 

32. 13 Interrupt Handling 

15 An IRQ Interrupt Model can be used with tiie RTOS, which means that the 

IRQ mtsmxpts are handled by conformant ISPs tiirough tiie OS Interrupt Supervisor 
and a subset of OS services can be used within tiie handlers. 

HQ interrupts need not be handled via tiie OS. Instead, FIQ interrupts can be 
configured as pseudo NMI, vMch means tiiat OS does not install the ISP mto tiie FIQ 
20 hard vector, tiiat the application calls to enable/disable interrupts do not affect tiie FIQ 
mfsmjpt and tiiat tiie handler cannot use any of tiie OS services. The application can 
still change tiie FIQ interrupt state directiy into tiie Current Program Statiis Register 
(CPSR) by calling an OS routine. The application can use another to mstall a FIQ 
handler into the hard vector. 
25 The API should provide tiie customer with tiie possibiUty to define an interrupt 

handling routine for a specific IRQ interrupt The offered API routine should caU tiie 
necessaiy OS procedures to install tiie entiy mto tiie hard vector. The API should not 
provide access to tiie customer for FIQ interrupts since most of tiiem are dedicated to 
really stringent Real Time activities dealing witii tiie BT Air Interface. 
30 Interrupts provide tiie key to fest response to external events occurring 

asynchronously in time. From time to time, tiie OS must inhibit interrupts whUe it 
performs a critical, indivisible sequence of operations. The OS keeps such intervals 
very short For instance, even whUe tiie OS is switching firom one task to anotiier, it is 
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able to respond to interrapts. In this case, it is possible that, as a result of servicing the 
interrupt, the OS may actually be instructed to switch to a task of higher priority than 
flie one which it otherwise would have picked, ffigher prioiiiy interrupts are nested 
within the ^pUcation interrupt handling - see Fig. 6. Only lower layer s determine the 
5 interrupt latency not the applications. This keeps any BT link alive and provides a 
guaranteed latency for the most critical events. 

When an interrupt occurs, most processors automatically vector to a user 
provided Mexrupt Service Procedure. If the device procedure wishes to use any of the 
available savices, it must notify the hiterrupt Supervisor that the interrupt has 
10 occurred. It is then fiee to use a subset of the services that are applicable to interrupt 
servicmg. These include triggering tasks for execution, sending messages to tasks, 
waking tasks and signaling events. 

Once the device has been serviced and the source of the mtetTiq)t cleared, the 
OS is notified with a call to the Interrupt SiQ)ervisor. 1^ as a consequence of servicing 
15 the interrupt, a task of higher priority than the intemq)tBd task is c^ble of execution, 
the OS will automatically initiate a task switch. If no hi^er priority task is ready to 
begin or resume execution, the OS returns to the mterrupted tasL 

To improve interrupt response, the OS permits nesting of interrupts on 
processors that support this feature. An extra HW register can be provided to handle 
20 this. 

When an mtemqrt occurs the processor saves enough processor dependent 
information to permit flie processor to resume the interrupted process. The ISP needs 
to save the registers is wishes to use, services the device, restores the registers, enables 
interrupt and returns to the execution program at the time of the interrupt 

25 

There are two types of ISPs: 



Non Conforming ISP: must quickly service the device to remove the 
interrupting condition, must preserve all the registers it uses, must not call any 
service procedures and executes in the context and stack of the process (task, ISP, 
kernel) which was interTq)ted. It should not allow to be interrupted by a 
conformiag ISP. 

Confi>rming ISP: consists of an ISP root and an Inteinqjt Handler. The 
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processor vectors to the ISP root, which informs the Internet Siq)ervisor that the 
interrupt has occurred. The Interrupt Supervisor preserves the state of the 
mtetrupted task and mi^t switch to an intemq)t stack. Then the Supervisor caUs 
the associated Interrupt Handler. This handler can use a subset of the service 
5 facilities. The interrupts with less or equal priority are disabled. 

The ARM core has two mterrupt Imes: IRQ and FIQ. IRQ intetnq>t handling has 
priority over any task in the system (including the Kemel Task that runs with the 
highest task priority). HQ interrupt handling has higher priority than IRQ a^^ 
10 therefore a nQ interrupt will preempt the servicing of an IRQ interrupt 

3.2.14 Exception Management 

The lowest level of exception handling is the one provided by the Fatal Exit 
procedure done when certain conditions are encountered which make the continuation 
15 of the execution unpredictable. In that case the OS forces a branch to a fatal error 
handler. The default implementation of this handler disables intemqrts and loops 
forever until a HW reset is performed. Dependmg on the developmenl/debugging 
platform, within the fetal error handler, means to log information via the UART for 
example can be provided. If appUcations (either customer code or API) encounter 
20 conditions yMck are deemed fatal (AppUcation Faults), they could call the fatal error 
handler with user defined exit codes. 

Another level of exception handling would be the provision of traps. Even 
though the OS could siqjport the definition of Task Error Traps (for enois like division 
by zero, overflow, etc. . .), the processor does not need to support such exceptions and 
25 therefore Task Error Traps need not be defined. 

The next level is the provision of User Error Procedures. Most OS procedures 
return an error status to the caller, but before doing so, the OS calls an User Error 
Procedure and passes the error code and the Task Id which was executing. The defeult 
User Error Procedure can ignore warmngs, but in case of errors a public break 
30 procedure can be called, e.g. by putting a breakpoint inhere so that all error 

conditions detected by the OS can be caught during testing. In this context the API can 
define its own (customer) negative error conditions or warning conditions to identify 
error conditions when calling the error procedure. In order to detect problems during 
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development, the API should provide extensive use of assertions and the possibility to 
trace/log debugging infonnation over the UART. The API will provide the means to 
switch on/off the tracing/debugging and the way different exceptions are handled 
depending on whether the target envkonment is deemed for development or for 
5 production (this switch could be done by a jimiper setting for example). 

The OS preferably provides the means to handle HW and SW exceptions. As 
indicated above, one is the use of a Fatal Exit procedure done when certain conditions 
are encountered which make tihe continuation of the execution unpredictable. In that 
case the OS forces a branch to a fatal error handler. The defeult implementation of this 
10 handler disables mterrupts and loops forever until a HW reset is performed. The 
following are examples of such conditions: 

• Insufficient memory: normally at startup when the Managers are initialiTing a 
portion of their private Data Segment If they need more data than the one 

15 provided in the System Configuration, the OS takes a fetal exit 

• Task Error Traps: each task can be assigned a Trap Error Handler routine 
which is called by the OS when th^e are errors like division by zero, overflow, 
etc. This trap can be assigned by a proper OS call. If the trap is not assigned or 
the pointer to the handler is null, the OS uses the fatal error handler. 

20 • Application Faults: if appUcations encounter conditions which are deemed 
fatal, the fatal error handler is called with user defined exit codes. 
Another possibility is tiie provision of User Error Procedures. Most OS procedures 
return an error status to the caller. Before doing so, the OS calls an User Error 
Procedure and passes the error code and the Task Id which was executing. The default 

25 User Error Procedure ignores warnings, but in case of errors a public break procedure 
is called. 

3.2.15 The OS Managers 

Some of the services of the OS are part of the core functionality and others are 
30 part of Managers that can be compiled m and out when configuring the system for a 
particular usage. The following is a list of possible managers: 

• Time/Date Manager [optional] 

• Sem^hore Manager [optional] 
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• Event Manager [optional] 

• Mailbox Manage* [optional if use of Message Exchange Manager] 
« Message Exchange Manager [optional if use of Mailbox Manager] 

• Buffer Manager 

5 • Memory Manager 

• Ckcular List Manager [optional] 

• Linked List Manager [optional] 

4, RTOS Abstraction layer 

1 0 Embodiments of the present invention may make use of a RTOS 

ABSTRACTION LAYER ^ch is a thin layer that aUows the BT Lower Layer 
software to be designed and implemented without knowing the specifics of the target 
RTOS kernel, i.e. an RTOS abstraction layer 1 L For example, SW does not need to 
call the RTOS directly but uses the RTOS ABSTRACTION LAYER instead. Fig. 4 

15 shows the relationship between the RTOS ABSTRACTION LAYER function calls 
and the target real-time operating system function calls. The BT Lower Layers that use 
the RTOS ABSTRACTION LAYER need not call the target real-tune operating 
system calls directly. 

The RTOS ABSTRACTION LAYER exports several functions to implement 
20 the following: 

• task communication 

• , memory management 

• software timers 
25 • signal queuing 



A RTOS ABSTRACTION LAYER task is a C function caU that never exits. 
Associated with the task is an input queue on which all signals sent to it are stored. In 
addition each task has a reserved area of memory called the stack. The stack holds 
30 local variables and function retum addresses. In general a task is designed to receive, 
process and then fi'ee the signals back to the system or send them on to otiier tasks. 



A task can be in one of three states : 
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• ruiming 

• ready 

• waiting. 

5 

Only one task can be running at any single point in time. The task with the highest 
priority that is ready to run will become the running task. If a task of higher priority 
becomes ready, the running task will be suspended and the new task of higher priority 
will start running. A task waiting for a signal to arrive on its input queue or waiting for 

10 memory to become available is held in the waiting state. 

If an interrupt occiurs, the running task is suspended and placed on the ready 
queue. The interrapt runs to completion after which the ready task with the highest 
priority will run. Note that the intemipt routine may have allowed another task of 
higher priority to become ready (by sending it a signal for example). 

15 Each task has one associated input queue on which all signals sent to the task 

are placed. Tasks cannot have more than one input queue. Signals are taken from tiie 
queue by "first in first ouf' (FIFO) order. Signals received by a task that needs to be 
stored for later processing can be held on internal queues. 

Tasks can start and stop one shot timers. The RTOS ABSTRACTION LAYER 

20 notifies a task that a timer has e?q)ired by sending it a timer expiry signal. 

4.1 Tasks and queues 

The RTOS ABSTRACTION LAYER permits a number of concurrent tasks to 
exist and communicate with each other. Tasks are declared to the system at 
25 configuration time and are created by the real-time kernel during kernel initialization. 
All tasks are static, which means they are created once and exist peraianentiy. It is not 
possible to dynamically create and destroy tasks through the RTOS ABSTRACTION 
LAYER, 

The RTOS ABSTRACTION LAYER creates the tasks by calling the dynamic 
30 task creation calls of the OS during startup. Therefore, in accordance with an 

embodiment of tiie present invention the API "extends" tiie RTOS ABSTRACTION 
LAYER to support that (i.e. better to add the functionality at RTOS ABSTRACTION 
LAYER than doing it at API level). 
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4.2 Task Communication 

Tasks communicate with each other using signals. A signal is composed of a 
unique reference id and a signal body (a C structure) held in dynamic memory. A task 
5 has to create the signal (reserve the dynamic memory), fill the contents and then send 
the signal to a defined task. The signal is stored on the destination tasks input queue 
until it is received. Once the signal has been sent, the sender no longer owns the 
memory associated with the signal. As soon as the destination task receives the signal, 
it becomes the owner of the associated memory. It is the responsibility of the receiving 
10 task to free the memory back to the system or send tiie signal to another task. 

4.3 Memory Msmagemeat 

The RTOS ABSTRACTION LAYER provides tasks with the faciUty to 
allocate, reallocate and fise blocks of dynamic memory. If memory is avaUable, the 
15 RTOS ABSTRACTION LAYER returns the start address of a block of memory that is 
at least as large as the size requested. The configuration of dynamic memory is specific 
to the target kernel and target appUcation. In general, however, dynamic memory is 
organized into one or more Memory Pools each containing a number of equally sized 
memory blocks. 

20 The number and size of memory blocks within each memory pool is defined at 

configuration time. The RTOS ABSTRACTION LAYER uses the static configuration 
and creation of memory pools offered by the OS. However, the OS offers as well tiie 
possibility to create tiie pools dynamically, and tiiis possibility can be exploited by the 
API. 

25 A library is compiled aheady and tiie amount ofRAM left is known for the 

person producing the application. Dynamically creation of the pools (as part of tiie 
customer specific startup sequence for example), is preferred. In this case tiie API can 
request the OS to do the creation in a controlled manner so that the available RAM is 
not exceeded. The present invention provides an extension to the RTOS 

30 ABSTRACTION LAYER fimctionality to provide fliis. 



4.4 Timer Management 

The RTOS ABSTRACTION LAYER provides a general-purpose mechanism 
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for starting and stopping software timers. A task can have multiple timers running 
concurrently. 

A task requiring use of a timer simply has to specify: 
5 • the duration of tiie required timer 

• the task to send the timeout to. This is optional if the task that starts the timer is 
always the recipient task. Since the OS provides a call to know the task's id of the 
current task, the API can fill this in v^thout the need for the customer to supply it 
This simplifies the prototype of this function. 
10 • a ViEilue (called user value) which identifies the timer to the recipient task. 

This information is passed to the RTOS ABSTRACTION LAYER, which returns a 
timer identity to the task. This timer identity is a number that uniquely identifies the 
software tim^ to tiie kernel, and to the task (in conjunction with the user value). 

15 The timer expiry signal contains the Timer Id and user value of the timer. 

When a task receives a timer expiry signal it must check the timer id specified in the 
timer expiry signal against a list of the task's active timers to ensure that the timer 
expiry signal is valid This avoids the problem where a timer has been stopped, but the 
timer e:q>iry signal is already in the recipient task's input queue. 

20 If repetitive time-outs are required, this can be achieved by restarting tiie timer 

after each timeout. The task has responsibility for maintaining a count of the number 
of time-outs. 

4.5 Internal Task's Queues (Unit Queues) 

25 The RTOS ABSTRACTION LAYER provides a facilily to queue signal bufiFer 

stractures for later processing. This permits a form of selective receiving (or signal 
prioritizing) of signals to be unplemented. A task requiring this facility must declare a 
unit queue structure in its own data space, and then use the RTOS ABSTRACTION 
LAYER function calls to manipulate the queue. This functionality can be provided in 

30 the API in case the customer's task needs to defer signals. 

4.6 Instantiation 

The RTOS ABSTRACTION LAYER provides macros m order to create 
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several tasks that use the same task function and these macros are expanded at 
compilation time. Each of these instances needs their own stack, queue and task id. 
One important user requirement is that the code must be reentrant 

5 J. Compildtion/Linking 

Ehiring the build process the user application source code 18 is compiled and 
linked together with a CFW library file 17 using a linker 1 9, in order to form together 
an .axf file 20 which is downloadable to the target platform of the telecommunications 
device. Fig. 7 gives an overview of the steps performed in the build procedure, 
10 The CFW library 17 is a library of software program products comprising a set 

of routines for an embedded software application requiring SW protocol layers, 
profiles and/or application code embedded on a processor, the library providing an 
interfece between the software application running on the processor and the SW 
protocol layers and/or the profiles and/or the application code. The CFW library 17 

15 comprises software for the RTOS 3, the RTOS abstraction layer 1 1, the RTOS 
libraiy,5 the lower layer stack 9 and the API 12 as detailed above. The lower layer 
stack 9 can be Bluetooth lower layer SW protocol. The CFW 17 library can be stored 
on a computer readable medium, such as a CD-ROM or DVD-ROM or a memory or 
data storage device, e.g. for delivery to the customer. 

20 For example, the BT stack (that includes the firework CFW defined to 

support the customer development) is delivered to the customer in the form of the 
CFW library or object file. The customer needs to compile and link their developed 
sources togedier witii the CFW library in order to obtain an image that can be run on 
the microprocessor of the telecommunications device. Hie customer uses the BT board 

25 prototypes. The complete program compiled by the customer, when executed on the 
microprocessor of the telecommunications device, runs ttie RTOS, the RTOS 
abstraction layer, the API, the telecommunications protocol stack, etc. as described 
above and hence provides all the functionality of all these items and the customer 
specific application progranL 

30 It is to be understood that although preferred embodunents, specific 

constructions and configurations, as well as materials, have been discussed herein for 
devices according to the present invention, various changes or modifications in form 
and detail may be made without departing fix)m the scope and spirit of this invention. 



